Ota provisioning to a secure element used for nfc transacations

ABSTRACT

A method for configuring a mobile communication device to perform transactions using a second communication channel that is different from a first communication channel through which the mobile communication device sends voice data. The method includes attaching a secure element to the mobile communication device. The secure element includes a memory storing an application, a processor configured to execute the application stored in the memory; and a wireless transceiver configured to send transaction data associated with the executed application through the second communication channel to a terminal that is remote from the mobile communication device.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of application Ser. No. 11/933,321,filed Oct. 31, 2007, which is a continuation-in-part of application Ser.No. 11/467,441, filed Aug. 25, 2006, now abandoned, which claimspriority to U.S. Provisional Patent Application No. 60/766,171 and U.S.Provisional Patent Application No. 60/766,172, both filed on Dec. 31,2005, all of which are incorporated by reference herein in theirentireties.

FIELD OF INVENTION

The present invention relates to data communications and wirelessdevices.

BACKGROUND OF THE INVENTION

Online transactions—e.g., for purchasing goods, receiving downloads, andso on—which involve personal computers and the Internet are well known.Further, wireless mobile communication devices, such as cell phones,blackberries or other personal digital assistants, are also being usedfor making transactions. For example, U.S. Patent Application No.US/2003/0172028 provides a description of a personal payment system thatutilizes a wireless enabled device such as a cell phone. As described,the personal payment system interacts using a Bluetooth protocol with aterminal located nearby the wireless enabled device. In another example,U.S. Pat. No. 7,031,945 describes a system and method that provides anelectronic ticket to a smart card or standard wireless device that isidentified with a user's account.

Further, wireless mobile devices that include a near field communication(NFC) device and a smart card (that uses an RFID for identificationpurposes) allow a person to securely make a simple transaction, such asfor example, purchasing a bus ticket. In such an example, the persontypically waves the wireless mobile device near a reader installed in abus, and a price of the bus ticket is deducted from a total amount thatis available and stored on the smart card of the wireless mobile device.Optionally, the amount of the bus ticket can be forwarded to a serverthat can identify the identification code of the particular RFID andthen subsequently charge the person for the purchase of the bus ticket.

While the references discussed above illustrate that certaintransactions are possible using wireless mobile devices, one problemassociated with the references are is that implementations described inthe references are not useful in a wide variety of different platforms,but rather are typically tied to a specific platform. For example, NFCdevices are only usable with NFC readers. Another problem is thatconventional wireless mobile devices generally have a very limitedability to be used in transactions.

BRIEF SUMMARY OF THE INVENTION

In general, in one aspect, this specification describes a method andsystem for configuring a mobile communication device to performtransactions using a second communication channel that is different froma first communication channel through which the mobile communicationdevice sends voice data. The method includes attaching a secure elementto the mobile communication device. The secure element includes a memorystoring an application, a processor configured to execute theapplication stored in the memory; and a wireless transceiver configuredto send transaction data associated with the executed applicationthrough the second communication channel to a terminal that is remotefrom the mobile communication device.

The details of one or more implementations are set forth in theaccompanying drawings and the description below. Other features andadvantages will be apparent from the description and drawings, and fromthe claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates one implementation of a block diagram of acommunication system including a wireless mobile communication device.

FIG. 2 illustrates one implementation of radio element in the wirelessmobile communication device of FIG. 1.

FIG. 3 illustrates one implementation of a wireless mobile communicationdevice.

FIGS. 4A-4C respectively illustrate an implementation of a secureelement in the wireless mobile communication device of FIG. 1.

FIG. 5 illustrates one implementation of a point of sale terminal.

FIGS. 6A-6D illustrate a flowchart for conducting a transactionaccording to one implementation.

FIG. 7 illustrates one implementation of a secure element that isattachable to a wireless communication device.

FIG. 8 illustrates a communication system in accordance with oneimplementation.

FIG. 9 illustrates a communication system in accordance with oneimplementation.

FIGS. 10A-10B illustrate example client user interfaces that aredisplayable on a display of the mobile communication device of FIG. 9.

Like reference symbols in the various drawings indicate like elements.

DETAILED DESCRIPTION OF THE INVENTION

This disclosure describes a communication system and method forassisting a user to complete a transaction. FIG. 1 illustrates oneimplementation of a communication system 100. The communication system100 includes a hand-held, wireless mobile communication device 110 that(in one implementation) includes a radio element 120 and a secureelement 130. A display 124 is shown associated with the radio element120, and antennas (not labeled) are shown as associated with each of theradio element 120 and the secure element 130. Each antenna canphysically be implemented in a manner that is different from thewireless antennas shown in FIG. 1. For example, an antenna can comprisea stripe that is passed along a reader, or comprise some suitabletransmission mechanism. Although elements 120 and 130 are shown asdistinct and separate, and display 124 is shown as connected to theradio element 120, other configurations are possible. In particular, acombination in which a single processor is used to execute the functionsthat are currently performed and described herein as being provided byboth the radio element 120 and the secure element 130. Further asillustrated in FIG. 1, both the radio element 120 and the secure element130 are internal to the mobile communication device 110, although inother implementations the secure element 130 can be external to themobile communication device 110, as described below. Also, variousdifferent functionalities can be included within the radio element 120and the secure element 130.

In one implementation, the mobile communication device 110 has thefunctionality to communicate with one of many different a point of sale(POS) terminals 150-1 to 150-n—e.g., in a contactless manner using awireless protocol. The mobile communication device 110 can alsosimilarly communicate with one or more point of entry (POE) terminals190-1 to 190-n. The point-of-sale terminal 150 receives one of thetransaction request signals from the mobile communication device 110 andtransmits the one transaction request signal to a transaction server170, typically using a communication channel 160 such as the Internet.The transaction server 170 verifies the transaction, and forwards atransaction verification signal to the management server 180. Themanagement server 180 identifies the user corresponding to thetransaction verification signal, and provides a first transactionresponse signal back to the mobile communication device 110 as one ofthe transaction signals.

In one implementation, the first transaction response signal iscommunicated back to the mobile communication device 110 using acommunication channel that is different from the communication channelused to initiate the transaction. In one implementation, differenttransaction response signals can be communicated back to the mobilecommunication device 110 using communication channels from themanagement server 180 to the radio element 120 associated with thedevice 110, as well as from the management server 180 to the secureelement 130 through the POS terminal 150 or the POE terminal 190.Further detailed descriptions of these implementations are discussed ingreater detail below.

FIG. 2 illustrates one implementation of the radio element 120associated with the mobile communication device 110, and illustrates theradio element 120 connected to the display 124 of the mobilecommunication device 110. In one implementation, the radio element 120includes a radio transceiver 122 that is adapted to send outgoing voiceand data signals and receive incoming voice and data signals over aradio communication channel. The radio communication channel can be adigital radio communication channel, such as CDMA or GSM. Such a radiocommunication channel has the capacity to communicate both voice anddata messages using conventional techniques. The radio transceiver 122communicates with a radio processor 123, which processor has thecapability to perform not only the radio communication servicesnecessary to allow for phone and data communications, but can alsoexecute various programs that are stored in the memory 126, whichprograms can receive inputs from the user via the display 124 and/or akeypad 125 associated with the mobile communication device 110.

In one implementation, application programs running on the radioprocessor 123 are, e.g., BREW or J2ME applications and can encompass abroad array of application types. For example, current applicationsinclude games, enterprise applications, and multimedia applications. Inone implementation, the radio processor 123 runs an application thatprovides movie and event information. Such an application can compriseticketing applications, content, item and service purchase applications,and/or payment management applications (referred to herein also as“wallet applications”). In one implementation, the radio processor 123also has the capability of recognizing secure communications, andtransmits data which must be stored in a secure environment to thesecure element driver 128 for transmission to the secure element 130. Inone implementation, in which both the radio element 120 and the secureelement 130 are internal to the mobile communication device 110,transmissions to the secure element 130 can take place using an internalwired communication channel. In one implementation, the radio processor123 also has the capability of receiving data from the secure element130, e.g., using the internal wired communication channel. In oneimplementation, the secure element 130 and the radio element 120communicate using signals described in the Java Card 2.1 Platform APISpecification.

In one implementation, both the radio element 120 and the secure element130 are disposed internally within a body of the mobile communicationdevice 110. For example, referring to FIG. 3, the mobile communicationdevice 110 is shown including a slot 400, which allows for the insertionof a secure element 130 into the slot 400. In this configuration, thesecure element 130 can be purchased independently of the mobilecommunication device 110. The secure element 130 can also be disposedinto a slot that only provides for physical insertion and mechanicalconnection to the body of the mobile communication device 110. In suchan implementation, the secure element can include a transceiver thatallows for the communication with the radio element 130 through awireless local communication channel. The radio element 120 also isillustrated as optionally including another transceiver 129, such as aBluetooth or WIFI transceiver, which can transmit and receive signalswith an external device and then communicate signals to and from theradio processor 123. This additional communication channel allows forcommunications between other external devices, such as an externalBluetooth enabled smartcard, and provides an additional communicationchannel that is useful for certain transactions, as described furtherherein.

FIG. 4A illustrates one implementation of the secure element 130associated with the mobile communication device 110. The secure element130 can be a smart card. In one implementation, the secure element 130includes a secure processor 132, a secure memory 133, and a POStransceiver 134 adapted to send transaction request signals and receivetransaction response signals over a first communication channel. In oneimplementation, the secure processor 132 communicates via the secureelement driver 128 with the radio processor 123 using signals asdescribed in the Java Card 2.1 Platform API Specification. Thetransaction request signals and the transaction response signalsassociated with the transaction can include an identification codeassociated with the user, as well as information relative to thetransaction, such as item, quantity, vendor, and so on. In oneimplementation, the POS transceiver 134 is an NFC device, which uses anNFC modem. The POS transceiver 134 can also be a Bluetooth, WIFI orother transceiver. In an implementation in which the POS transceiver isan NFC modem, such an NFC modem will typically have a set of registersthat can be read/written by the secure processor 132. These registersare in turn available for reading and writing over the RFIDcommunications channel and serve as a shared memory between the secureprocessor 123 within the secure element 130 and the RFID reader that isassociated with the POS terminal 150. This communication is specified,for example, in the ISO 14443A/B standard. The secure element canoptionally include a radio/Bluetooth/WIFI transceiver 136, which cancommunicate with other devices, such as a transceiver associated withthe radio processor 120 or for other external devices having thosecommunication capabilities, thus allowing for more flexibility.

FIG. 4B shows another implementation of a secure element 130, in whichthe radio element 120 does not communicate with the secure element 130through a secure element driver 128. In this case, for example, thesecure element 130 may be external to the mobile communication device110 and as such is not connected to the radio element through the secureelement driver 128. In such an implementation, however, if thetransceiver 136 as described above is included, and a similartransceiver 129 associated with the radio element 130 as describedpreviously with respect to FIG. 2 is included, then this communicationchannel can be used to wirelessly obtain direct communications betweenthe radio element 120 and the secure element 130. This implementationallows for certain bidirectional communications with other devices, aswell as with the radio element 120, and as such more functionality andflexibility is achieved. This implementation is particularly usefulsince it establishes a direct local communication path with the radioelement 120, since there is not communications with the radio element120 via the path of driver 128.

This implementation allows for certain bidirectional communications withother devices, as well as with the radio element 120, and as such morefunctionality and flexibility is achieved. This implementation isparticularly useful for establishing a direct local communication pathwith the radio element 120, since there are no communications with theradio element 120 via the path of driver 128. If either of thetransceivers 129 or 136 are not associated with the respective radioelement 120 or secure element 130, and there is no direct connectionbetween the radio element 120 and the secure element 130, then a directcommunication link between the radio element 120 an the secure element130 will not exist. As such, while ticketing and many transactions canstill exist, data from a real-time transaction performed using thesecure element 130 cannot be made directly available to the radioprocessor and the applications stored thereon. In such animplementation, certain redundancy checks may not occur. For example, aticketing application can be programmed to provide an alert if a ticketreceipt has not been received within a certain period of time. Such analert would not be possible to program directly (although it could beprogrammed indirectly via the button panel on the phone).

FIG. 7 illustrates one implementation of a secure element 130 that canbe attached (or affixed) externally to a wireless communication device(e.g., mobile communication device 110). In one implementation, thesecure element 130 has circular shape. The secure element 130 can haveother suitable shapes—e.g., rectangular, triangular, and so on. In oneimplementation, the secure element 130 includes an embedded smart chip702 that is capable of executing proximity services (e.g., servicesrelated to payments, ticketing, identification, sending coupons, etc.).In one implementation, the smart chip 702 is capable of 2-way wirelesscommunication (e.g., RFID, NFC, Bluetooth, etc.) with a supporting3rdParty terminal. In one implementation, the 2-way communication isperformed using a communication protocol that is different from acommunication protocol through which the mobile communication devicesends or receives voice and/or data signals. Multiple applicationprotocols (NFC, MiFare, etc.) can be supported. In one implementation,the smart chip 702 is programmable. Accordingly, different application(for payments, ticketing, identification, coupons, etc.) can bedeveloped, downloaded to the smart chip, and commissioned. Thus inoperation, in response to the secure element 130 being placed in closeproximity with a suitable terminal, the terminal will trigger (viaapplication protocol) an appropriate application stored in the smartchip, and the smart chip will respond appropriately with the terminal.

In one implementation, the smart chip uses a low-power RFtransmitter/receiver to communicate with a terminal. The low-poweroutput of the smart chip makes it susceptible to RF interference fromneighboring devices. Specifically problematic are components associatedwith the mobile communication device, e.g., battery, antennae (internalor external), to which the secure element 130 is affixed. Thus, in oneimplementation, the secure element 130 includes an RF shield to insulatethe smart chip from external interference. In one implementation, alining of the secure element 130 is composed of an RF absorbentmaterial/lining. In general, each phone has different levels ofinterference, and a material, size and thickness of the RF lining candetermine an effectiveness of the RF shield. In one implementation, anRF shield can be placed between the secure element 130 and the mobilecommunication device 110.

Given the abuse a mobile communication device can take, components thatare affixed externally to a mobile communication device need to be ableto withstand some abuse. Thus, in one implementation, the secure elementincludes a ruggedized shell 704 that encases a smart chip (withantennae). In one implementation, the shell 704 is formed from acomposite plastic or polymer. The shell 70 can be hard (andsubstantially inflexible) or be soft (and pliable). In oneimplementation, the shell 704 provides a protective membrane for thesmart chip which prevents damage to internal circuitry, a surface toadhere to an RF lining and/or a mobile communication device withappropriate adhesive, and a surface to print branding and advertising.Types of adhesives that can be used to affix the secure element 130 to amobile communication device include, for example, paper glue, superglue, polymers, and the like. In one implementation, the shell 704 has amaximum width (or diameter) of 25 mm, and has a maximum thickness (ordepth) of 5 mm.

FIG. 4C shows another implementation of a secure element 130, in whichthe secure element 130 does not include a processor that is capable ofbidirectional communications, but instead includes a passive device 138.The passive device 138 can be an RFID sticker or suitable tag thatallows for uniquely identifying a user, such that a transaction that isinitiated with the passive device 138 will cause the management server180 to perform transaction details. In this implementation, the codereceived from the POS terminal 150 (or the POE terminal 190) istransmitted from the POS terminal 150 (or the POE terminal 190) to themanagement server 190, which then takes over the transaction. Thispassive device 138, with the identification code stored thereon, canthus be associated with a mobile communication device 110 not otherwiseequipped for such communications, and the management server 190 canprovide transactional information to the mobile communication device 110using available channels on the mobile communication device (such asaudio, SMS, or other known data transmission methods). Whilebidirectional communications do not occur with other devices,transactions are possible, because the management server 190 isinvolved.

SMS (Short Messaging Service) as a Data Transmission Method

As discussed above SMS (Short Message Service) can be used as a datatransmission method between the management server 190 and the mobilecommunication device 110. SMS is generally unstructured. Thus, whenmessages arrive in an inbox of a user inbox, the user cannot easilysearch, retrieve, or organize the messages. In addition, due to SMS'ssend-and-forget characteristics, it cannot be assumed that messages arereceived by the terminating point, or if received, received in aparticular sequence. FIG. 8 illustrates a communication system 800 inaccordance with one implementation. The communication system800 includesa mobile communication device 802 that communicates with a remote server804 (e.g., a transaction server) via SMS. The mobile communicationdevice 802 includes a mobile application 806 that receives SMS messagesfrom the remote server 804 and organizes the SMS messages (includinglinking corresponding messages into a pre-determined order) so that datacan be stored and displayed to a user in an organized and easilyretrievable fashion, unlike a conventional application that implementsSMS as a data transmission method in which SMS messages remain in anunstructured format and are unlinked. Such an unstructured format doesnot allow the user to retrieve, organize, or manage the display ofmessages. The mobile application 806 can be, for example, a J2ME, BREW,Windows Mobile, or other type of application.

In one implementation, the mobile application 806 is a rich clientapplication (also commonly referred to as a fat client application orthick client application). A rich client application is a clientapplication that performs the bulk of any data processing operationsitself, and does not necessarily rely on a server (e.g., remote server804). The mobile application 806 can also be a thin client applicationor hybrid client application. In one implementation, the mobileapplication 806 is the Blaze Mobile Wallet Lite application availablefrom Mobile Candy Dish Inc. or Berkeley, Calif. In one implementation,the mobile application 806 provides banking and money managementtransaction services, and transmits data from the wireless communicationdevice 802 via SMS in accordance with a connectionless protocol.

FIG. 9 illustrates a communication system 900 in accordance with oneimplementation. The communication system 900 includes a mobilecommunication device 902, a management server 904, a user/profiledatabase 906, and a money management database 908. In oneimplementation, the management server 904 is a Blaze server. In oneimplementation, the mobile communication device 902 stores a mobileapplication 910 that uses short message service (SMS) over aconnectionless protocol to transmit data to the management server 904.SMS permits the mobile application 910 to send messages of a fixed size,for example, up to 160 characters, to and from the wireless mobilecommunication device 902. In one implementation, the management server904 includes an SMS aggregator 912 to aggregate each message receivedfrom the wireless mobile communication device 902 and keep track of theordering of each message, and (in one implementation) also groups eachmessage into a corresponding group. In one implementation, the mobileapplication 910 also includes an SMS aggregator (not shown).

Thus, in one implementation, the mobile application 910 is not browserHTTP based, and delivers banking and money management services. Themobile application 910 also leverages a low-end communicationinfrastructure (also referred to herein as a “bearer service”). A bearerservice that is universal on all mobile devices is the Short MessageService (SMS). SMS is a means of sending short messages to and frommobile phones to the Application Service Provider (ASP) Server “Server”.It is inherently a connectionless communication protocol, i.e., send andforget. There is no acknowledgement to the Mobile Originating (MO)sender that the message sent was successfully received by the MobileTerminating (MT) recipient. There is no concept of timeouts, messagelost, message not received, etc. Leveraging SMS as a bearer service tosupport a ‘rich’ client application. The Client will listen to aspecific incoming SMS port to be defined based on NetworkOperator/Carrier, Phone Vendor, etc.

In one implementation, the mobile application 910 provides banking andmoney management service, which includes (but is not limited to):

-   -   Registration: User creates new MW Lite account with PIN (PIN and        user info can be stored in user/profile database 306)    -   Security & Encryption: Sensitive information may optionally by        encrypted using 3rdParty or native phone tools (Bouncy Castle,        etc.). Encryption (Public/Private) keys may be managed or        proxy'd by Server which may additionally be out-sourced to        3rdparty Key Management vendor.    -   Install & Configuration (I&C): Refers to setting up proxies to        -   payment accounts (virtual, credit, debit & banking)        -   Payees (BillPay, PayAnyone, etc.) and associated rules        -   Specify default payment account to debit fund            transfers/unloading        -   Specify default payment account to credit fund            transfers/loading        -   Activation of 3rdParty Services (Account Balance, Bill Pay,            Fund Transfer, Funds Loading, Funds Unloading)        -   It is assumed Client application is pre-installed or            downloaded to mobile device.        -   I&C to be performed via Kiosk, ATM, 3rdParty/Carrier Web            Portal, MCD Web Portal, on mobile device, or other suitable            device.    -   Loading Funds    -   Banking or financial data        -   Account balance        -   Transaction history        -   Bill Pay-Biller Direct        -   Fund Transfer-Intra Bank; Me-2-Me        -   Fund Transfer-Inter Bank; Me-2-Me        -   Fund Transfer-Inter Bank; Me-2-You (based on Bank            Routing/Account#)        -   Fund Transfer-Inter Bank; Me-2-You (based on WalletID)        -   Fund Transfer-Inter Bank; Me-2-You (based on ACH Check).            A.k.a. Bill Pay Anyone        -   Load Fund    -   Unload Funds (ATM Withdrawal, etc.)    -   Sync: Ensures server-side objects are downloaded to client and        locally cached. This includes payment accounts, payees, payment        rules, server-side cached account info (account balance, Last-N        transaction history), etc.        -   This info will be cached on Client.        -   Users can create transaction either in ONLINE or OFFLINE (no            network connectivity) mode    -   Initiating/Triggering Banking Services:    -   Storage: Storage of Users MWLite info, User's payment account        info (credentials, account balance, history, etc.); Banking        Payment History (BillPay, Fund Transfer, Fund Loads, Fund        Unloads, etc.)

Scenarios/Features

1. Overlaying connection protocol properties over SMS. This includes:segmenting complex command and control (C&C) messages into 1 or more SMSmessages, and re-constructing one or more SMS messages into complex C&Cresultset messages. Re-constructing the one or more messages intocomplex C&C resultset messages can include one or more of the followingproviding acknowledgement, handling out-of-sequence incoming messages,handling unexpected messages or messages considered lost (due totimeout, etc.), Managing encryption as needed, and so on.

2. User uses the mobile application 910 to initiate/trigger appropriatebanking service. For example, referring to FIG. 10A a user can initiatea bill paying service through which a payee (e.g., PG&E) can be paid. Inone implementation, the display of the bill pay screen can include anadvertisement as shown in FIG. 10A.

3. The mobile application 910 formulates appropriate banking servicescommands, for example:

-   -   “<command> <PaymentAccount> <Payee> <$amt> <tarnsferDate> <PIN>        <sequenceID> <message> <messages>”        -   billpay MCC-2345 PG&E 110.23 20070328 1234 36 1 1        -   transfer bofa-1007 jdoe 25.00 20070328 1234 36 1 1#where            jdoe is a walletID        -   transfer bofa-1007 8005550001 25.00 20070328 1234 36 1            1#where 8005550001 is the phoneNumber of unloading station.        -   fundstransfer bofa-1007 gwbush 30.00 20070328 1234 36 1            1#gwbush is a payee    -   “<command> <PaymentAccount> <PIN> <sequenceID> <message>        <messages>”        -   Balance bofa-1007 1234 36 1 1

4. A Loading Station (Kiosk, etc.) can load funds by sending command toMCD's Loading Shortcode.

-   -   “<command> <PaymentAccount> <Payee> <$amt> <transferDate> <PIN>        <sequenceID> <message> <messages>”        -   load CorpBankPayrollAccount-2007 8005550001 4000.00 20070328            0987 43 1 1 (#Debit account CorpBankPayrollAccount-2007 by            $4000 and credit account held by user with phone Number            8005550001)

5. Receive multiple (in/out sequence, missing, lost, etc.) messages toreconstruct a complex messages.

-   -   <sequenceID>:<message>:<messages>; <body>        -   “36:1:6; acct:Bofa-1007 bal:40123.32 date:20071009”        -   “36:3:6; date:20071009 name:Merchant2 amt:123.81”        -   “36:6:6; date:20071009 name:Merchant5 amt:423.81”        -   “36:4:6; date:20071009 name:Merchant3 amt:223.81”        -   “36:2:6; date:20071009 name:Merchant1 amt:23.81”        -   “36:5:6; date:20071009 name:Merchant4 amt:323.81”

In one implementation, post processing of these multiple messagesresults in the screen shown in FIG. 10B which displays the accountbalance and the last five transactions in a transaction history list.The list can be cached on the mobile communication device 902 for lateruse.

6. Cashed data is refreshed upon user request. This in turn invokes acommand similar to the following:

-   -   <command> <account> <PIN> <sequenceID> <message> <messages>        -   Balance Bofa-1007 1234 37 1 1 (# Where 37 is the next            <sequenceID>)

Connection Protocol Properties

The above description introduced the concept on <sequenceID> <message><messages>. The sequenceID is a rotating pool per Client, issued by theClient, used as a callback mechanism, i.e., match outgoing commandmessages and incoming resultset messages. Since resultsets can be longand complex, the resultset is broken into pages, where each page can fitwith the allowed payload size of an SMS message. Hence, “<message><messages>” implies “Page 1 of 5”. The Client (or mobile application)then has to wait for all <messages> to arrive before re-constructing theoriginal resultset. Due to characteristics of SMS, the client has tohandle scenarios when a message with an un-expected sequenceID arrives.In addition, if a missing page within the expected sequenceID fails toarrive within a specified time interval, the client needs to requestretransmission, e.g., “retransmit 36:4:6 1234” which will instructserver to retransmit resultset 36, part 4 of 6.

The pool size (or range of valid sequenceID's) controls the asynchronousaspect of the application. The sequenceID is mapped to the command (atleast until the sequenceID is re-used). Hence, the client will use thesequenceID to determine to command and associate the appropriate displaystyle sheet to best display the resultset to the user. For example, ifsequenceID=36 was issued by the command ‘balance’ which determinesaccount balance, it makes sense to leverage the ‘Account Balance &History’ style sheet to present this information.

SMS messages to and from the mobile communication device has to beacknowledged. A simple protocol is necessary, for example, as follows:

-   -   1. # Mobile Originated (MO) command        -   <command> <body> <sequenceID> <message> <messages>        -   balance Bofa-1007 1234 37 1 1    -   2. # Server, a.k.a., Mobile Terminating (MT) receives and        acknowledges receipt of message ‘37 part 1 of 1.”        -   ack 37 1 1    -   3. # MT responds with resultset        -   36:1:2; acct:Bofa-1007 bal:40123.32 date:20071009    -   4. # MO receives and acknowledges receipt of message ‘36 part 1        of 2.”        -   ack 37 1 2    -   5. # MT responds with resultset (part 2 of 2)        -   “36:2:2; date:20071009 name:Merchant1 amt:23.81”    -   6. # MO receives and acknowledges receipt of message ‘36 part 2        of 2.”        -   ack 37 2 2    -   7. # MO has received all messages. Reconstruct & store message    -   8. # Next time user view account balance, display cached (local        store) information:        -   Bank Account: Bofa-1007        -   Balance: $40,123.32 as of Oct. 9, 2007        -   10/9/2007 Merchant1 $23.81

Online/Offline Access

In one implementation, a mobile communication device createstask/objects either while connected with a Server (online-mode) or whenno connection is available (offline-mode). Tasks/objects are specific tomobile banking service and include for example: schedule (or cancel) afund transfer transaction, schedule (or cancel) a bill pay transaction,and manage other banking transactions. In addition, digital artifacts(coupons, tickets, etc.) that possess a state (or status) (e.g.,Assigned, Saves, Redeemed, Deleted, etc.) can undergo changes on themobile communication device. Given these tasks/objects associated toBanking Services and Digital Artifacts has ‘states’ that can be changedin either an online-mode or offline-mode, the Server has to berefreshed/updated either in real-time (online-mode) or in batch(offline-mode).

For example, given a situation in which a user is travelling in a regionin which the user's mobile communication device does not have networkaccess and the user needs to transfer funds into a checking account, theuser can use the mobile communication device (with the Mobile WalletClient application) to schedules a fund transfer in offline mode. Sincethe mobile communication device has no network connectivity, the Client(in OFFLINE mode) creates a ‘task’ to represent the fund transfer (orany other banking service) using banking information (Banks accounts,etc.) previously cached on mobile device. The task can have an initialstate (e.g., “pending”). While the Client is enabled the Client willactively monitor network access. When the user travels into a regionwhere network access is available, the client will identify the networkand automatically re-connect to the network. The client will thennegotiate with a server and any tasks having a “pending” state on theclient are then uploaded to server (either in batch mode or one task ata time). The client (in ONLINE mode) will refresh states of all taskfrom the server (including the recently added tasks) to present to theuser the updated status of all tasks managed by the server. Otherservices possible include, for example: request schedule (orcancellation) of Bill Pay transaction, request schedule (orcancellation) of Fund Transfer transaction, request schedule (orcancellation) of Pay Anyone transaction, any other state-based bankingtransaction service.

Using the client (or mobile application), a user can store digitalartifacts (e.g., coupons, tickets, etc.) on a mobile communicationdevice. These digital artifacts are objects that are consumed by a3rdParty, e.g., a ticket can be redeemed at a theater, and a coupon canbe redeemed at the Point-Of-Sale of a retail merchant. Hence, this is a3-way sync: 1) mobile communication device with server, 2. mobilecommunication device with 3rdParty Merchant, and 3) server with 3rdPartyMerchant. For user's convenience, redemption of digital artifacts by a3rdParty must be enabled in an environment with or without networkaccess. For example, a user with an electronic ticket on a mobilecommunication device may wish to redeem an eTicket at a theater.However, if there is no network access inside the theater, the user willstill need access the eTicket on the client. In ONLINE mode, the clientwill cache (local store) the eTicket (and any other digital artifact.)In the theater, the client (in OFFLINE mode) will be able to redeem theeTicket and update the state of the eTicket on the mobile communicationdevice (e.g., change state from ‘valid’ to ‘redeemed’). This preventsthe user from re-using the eTicket. At some point when the mobilecommunication device re-acquires network connectivity, the client willthen negotiate with the server and any artifacts with a state change(e.g., ‘valid’ to ‘redeemed’, etc.) on the client are then uploaded tothe server (e.g., either in batch mode or one task at a time).

The client (in ONLINE mode) will manage and refresh states of allartifacts from the server (including the recently added tasks) topresent to the user. In one implementation, the server is the masterrepository. In the process of redeeming the eTicket, the eTicket isuploaded to the merchant (via secondary out-of-band communication link,e.g., RFID/NFC, Bluetooth, etc.). This is necessary for theater toupdate their inventory systems. The 3rdParty may liaise (via an internetconnection) with the server to validate eTicket and authenticate theuser.

POS (Point of Sale) Terminal

The point of sale terminal 150 illustrated in FIG. 5 is conventional, inthat it has the capability of electronically reading information from adevice equipped to transmit information in a format that it reads. Thus,the reader 152 within the point of sale terminal 150 can be of one ormany types. If the point of sale terminal reader 152 includes theprovision for NFC communications, then simply bringing the secureelement 130 with the NFC transceiver will cause initiation of atransaction and the transmission of the identification code associatedwith the secure element 130 and thus the user.

In one implementation, various software that is downloaded into thememory 126 of the radio element 120 and the secure memory 132 of thesecure element 130, along with software resident on the managementserver 180, cooperate at a layer that is above the physical layer of thecommunications, in order for the desired transaction to occur. Thissoftware is implemented using based upon known knowledge of mobilecommunication device 110 internals and application platforms, NFC,smartcard internals and application platforms, payment protocols (e.g.PayPass), and the working/workflow associated with POS and POEterminals, and the transaction and management servers. In addition, thepresent invention provides for piggybacking a tunneling protocol on topof the payment protocol, so that the secure elements 130 can communicatewith the transaction server 170 and/or the management server 180,without modification to the POS terminal 150 or the POE terminal 190. Assuch, this includes software within the secure element 130 that embedsthe required information in fields which will not adversely affect theperformance of the POS terminal 150 and/or the POE terminal 190, andalso software in transaction server 170 that will extract thepiggybacked payload, associate the payload with the management server180 if needed, and then authenticate, authorize, and execute transfersof transaction information to the management server 180. In oneimplementation, the piggybacked payload is sent, instead of to thetransaction server 170, to the management server 180, which can thenassociate the transaction and notify the transaction server 170, the POSterminal 150 and/or the POE terminal as needed.

In one implementation, the management server 180 has the capability ofstoring codes that are from a variety of different mobile communicationdevices. Thus, codes that are associated with a smart card having anRFID can be stored, as can be codes stored from an RFID sticker, as wellas codes that are associated with a smart card that communicates using aslide reader, Bluetooth, or an NFC channel, for example. As such, themanagement server 180 can store user personal and credit andtransactional information and history, including a code associated withthe user, for a variety of different mobile communication devices,thereby allowing a system which can scale.

FIGS. 6A-6D illustrate a flowchart of a transaction in accordance withone implementation, and the various steps that are included in thetransaction, with reference to which of the various devices areimplementing this step. Referring to FIG. 6A, a user first waves amobile communication device 530 (e.g., a NFC device or device having anattached sticker) across (or near) a POS terminal 540. The POS terminal540 identifies the technology associated with the mobile communicationdevice, a payment method, user credentials, and payment credentials.Irrespective if t mobile communication device is a NFC-Phone or includesan attached sticker, the mobile communication device sends to the POSTerminal 540 payment credentials including optional credentials (e.g.,WalletID). As shown in FIG. 6B, using optional credentials (e.g.,WalletID), contact is made with a transaction server 510 to requestpayment credentials. The POS terminal 540 determines if a security codeprompt (e.g., a PIN) is needed? If yes, a prompt is made for thesecurity code (PIN) on the POS terminal 540 and the process continueswith processing of the payment. Otherwise, the POS terminal 540 simplyproceeds with processing of the payment. As an alternative, the POSterminal 540 can integrate via the back office to a management server510 and trigger a PIN prompt on the mobile communication device. In sucha case, the user can enter the PIN on the mobile communication device(instead of through the POS terminal 540). The POS terminal 540 handsprocessing to a payment broker.

Referring to FIG. 6C, assuming the POS terminal 540 was capable of 2-waycommunication, if the POS terminal 540 determines that the mobilecommunication device is a NFC Phone, the POS terminal 540 can writedigital artifacts (e.g, eReceipts, eTickets, eCoupons, etc.) to themobile communication device. Non-secure data is stored in the mobilecommunication device. Otherwise, the POS terminal 540 sends optionaldigital artifacts to the management server 510. As part of anout-of-band sync between the management server 510 and the mobilecommunication device, the non-secure digital artifacts are downloadedand stored in the mobile communication device. Secure digital artifactsare downloaded to the mobile communication device and stored on a secureelement of the mobile communication device (if possible).

In FIG. 6D, upon successful payment processing and assuming the POSterminal 540 was capable of 2-way communication, if the POS terminal 540determines that the mobile communication device is not an NFC Phone, thePOS terminal 540 triggers the management server 510 of paymentprocessing completion. Note, this can be time delayed due to adifference when a payment is posted and cleared. The management server510 can send a notification to the mobile communication device (via SMS,etc.). Since the mobile communication device could be shutdown, thenotification will wake-up the mobile application running on the mobilecommunication device, and initiate SYNC operations between themanagement server 510 and the mobile application (or client). Anypending digital artifacts (including notifications, etc.) are displayedon the mobile communication device.

The present invention, as described previously, allows for variousdifferent programs to exist within the memory 126 of the radio element120, as well as in the secure memory 132 of the secure element 130.

Mobile Tickets (eTickets)

In one implementation, a mobile ticket (also referred to herein as“electronic ticket” or “eTicket”) includes both a unique code that issent to the consumer's cell phone and a database that allows for thevalidation of the consumer using their cell phone number and the uniquecode. The mobile ticket can be used at kiosks in addition to interfacingwith a ticket agent. The mobile ticket may be used with or without cellphones equipped with radio technology (i.e., RFID or NFC). In operation,a mobile ticket works when the user is sent a unique code(alpha-numeric, numeric, etc.) to their cell phone. The user isvalidated as a customer by their cell phone number and their code. Ifthese match the information stored in a central database, the user isallowed admission into a venue by either manual validation by a ticketagent or automatically using RFID or NFC technology.

In general, an electronic ticket can be delivered to a mobile device andallow a consumer admission into a sports venue, entertainment venue(e.g. concert or movies), or other point of sale location eithermanually if the consumer displays the electronic ticket to an agent whomay issue a paper ticket to the consumer or automatically if theconsumer waves their cell phone (if equipped with a radio transmitter)over a POS device which contains a radio receiver. In oneimplementation, an electronic ticket (or tickets) is selected by viewingan image of the venue seating map. The seating map can be rendered onthe mobile device. Users can zoom in/out of the seating map. As Userzooms in, additional layers (details, info, etc.) is presented. Forexample, a user can view Venue->Quadrant->Level->Section->Row. Theability to zoom in/out and present additional levels of details can beprocessed either on the mobile device (Client) or on the Content Server,the end result is an updated image rendered on the mobile device. In oneimplementation, seats are color coded to represent availability andprice. In this manner, seat inventory (what's available and at whatprice) can be illustrated graphically. Once user has navigated to lowestlevel, the image is granular enough to select individual seats. In oneimplementation, a seat selection will automatically cause a price to becalculated. Any service fee can be included in the ticket price. Onceuser confirms purchase, reservation request is sent to ticket inventorysystem. If reservation is successful, a valid electronic ticket isreturned to the mobile device.

The present invention can also be interfaced with certain known andimplanted payment protocols, such as Paypass. For implementing theseadditional payment protocols, implementation of streaming communicationprotocols (in the full NFC case), protocols for session setup, andconfiguration of communications modules and secure data areas as neededis necessary, taking into account the communication protocol used (e.g.NFC, Bluetooth, WIFI, CDMA, 3.sup.rd Generation CDMA for example) aswell as file transfer protocols and facilities access protocols. Inparticular, in implementing such protocols, the ability to extracttransaction information from the POS terminal 150 to the secure element130 can be provided during the course of the local interaction betweenthe POS terminal 150 and the secure element 130. For instance, theimplementation of PayPass within the invention will take note, and alertthe application running on the radio processor 123 that a purchase orpurchase attempt has occurred, as noted above in the context of thealert discussion. In one implementation, a feature is provided thatpermits information passed via the PayPass protocol to the POS terminal150 (and thence to the transaction server 170) to be augmented withadditional fields containing the elements of the tunneling protocol, forsubsequent processing by the transaction server 170, either directly, orthrough the management server 180.

The two transaction workflows that have been specifically discussedabove are the credit card and ticketing workflows. Other transactionflows can also be implemented. Debit card and cash card transactions aresimilar to credit card transactions, with variations being implementedto account for the differences that exist in those types oftransactions, which types of transactions are well understood. Couponscan be implemented with the invention, in much the same manner astickets, though coupons can be transmitted without there being payment.Many of the transaction types noted herein will, as is apparent, requirecommunication between the secure element 130 and the radio element 120.As such, due to that requirement, a significant part of the precedingdiscussion has been directed to how to implement that communication,particularly for mobile communication devices 110 that are notmanufactured to allow for such communications.

An example of a typical transaction requiring such communication betweenthe secure element 130 and the radio element 120 is one in which the POSterminal 150 allows for the transfer of detailed purchase informationfrom the POS terminal 150 to the secure element 130, as well astransactional information from the POS terminal 150 and/or thetransaction server 170 to the management server 180. The managementserver 180 can then also communicate with the radio element 120 via theradio channel. This allows for the matching and reconciliation ofdetailed purchase information and, if the transaction fails, failuredetails can be matched to the purchase information, and forwarded inreal-time to the user via the radio element 120. In one implementation,there is included the provision for different phones to communicate theresults of a transaction, particularly using the POS transceiver or oneof the Bluetooth/Wifi transceivers. In this implementation, after atransaction has been completed with one of the mobile communicationdevices 110 a, another mobile communication device 110 b can receiveinformation regarding the transaction completed. Thus, for instance, ifmobile communication device 110 a purchases two tickets, one of thetickets can be transmitted to the mobile communication device 110 b byeach using a POS transceiver or one of the Bluetooth/Wifi transceivers.

Although the present invention has been particularly described withreference to implementations discussed above, various changes,modifications and substitutes are can be made. Accordingly, it will beappreciated that in numerous instances some features of the inventioncan be employed without a corresponding use of other features. Further,variations can be made in the number and arrangement of componentsillustrated in the figures discussed above.

1. A method for provisioning applications configured for near fieldcommunication (NFC), the method comprising: downloading an applicationconfigured for NFC transactions from a remote server to a secure elementmemory included in a secure element, the secure element coupled to amobile device, wherein the secure element includes a first transceiverconfigured for NFC and communications with a point-of-sale (POS) orpoint-of-entry (POE) terminal and a second transceiver configured tocommunicate with the remote server, wherein the secure element memory isseparate from a mobile device memory included in the mobile device;executing the application included in the secure element memory inresponse to an NFC trigger by the POS or POE terminal.
 2. The method ofclaim 1, wherein the NFC trigger is induction based.
 3. The method ofclaim 1, wherein the second transceiver is a radio transceiver.
 4. Themethod of claim 1, wherein the second transceiver is a Bluetooth™transceiver.
 5. The method of claim 1, wherein the second transceiver isa wireless fidelity (WiFi).
 6. The method of claim 1, wherein the secureelement is electrically coupled to the mobile device.
 7. The method ofclaim 1, wherein the secure element is physically coupled to butelectrically disconnected from the mobile device.
 8. The method of claim1, wherein the application is downloaded to the mobile device memory andtransferred to the secure element memory using the second transceiver.9. The method of claim 1, wherein the secure element memory stores anidentifier that corresponds to a user of the mobile device, whereintransaction data includes the identifier.
 10. The method of claim 1,wherein the application is executed during a ticketing, content,service, or payment management transaction.
 11. The method of claim 10,wherein the application is executed using a secure element processorincluded in the secure element.
 12. The method of claim 1, wherein thesecure element includes a smart chip.
 13. The method of claim 1, whereinthe secure element is electrically coupled to the mobile device.
 14. Themethod of claim 1, wherein the secure element is removably inserted intoa slot electrically connected to the mobile device.
 15. The method ofclaim 1, wherein the secure element is embedded within the mobiledevice.
 16. The method of claim 1, wherein the secure element includes aradio frequency (RF) absorbent material in an outer shell housing thesecure element to shield the secure element from interference generatedby the interior components of the mobile device, wherein the outer shellhas a maximum width of 25 mm and a maximum thickness of 5 mm.
 17. Asecure element comprising: a first transceiver configured for near fieldcommunication (NFC) transactions with a point-of-sale (POS) orpoint-of-entry (POE) terminal; a second transceiver configured toreceive an application configured for NFC transactions from a remoteserver; a secure element memory configured to maintain the application,wherein the secure element memory is separate from a mobile devicememory in a mobile device coupled to the secure element; a secureelement processor configured to execute the application in response toan NFC trigger by the POS or POE terminal.
 18. The secure element ofclaim 17, wherein the NFC trigger is induction based.
 19. A system forprovisioning applications configured for near field communication (NFC),the method comprising: means for downloading an application configuredfor NFC transactions from a remote server to a secure element memoryincluded in a secure element, the secure element coupled to a mobiledevice, wherein the secure element includes a first transceiverconfigured for NFC and communications with a point-of-sale (POS) orpoint-of-entry (POE) terminal and a second transceiver configured tocommunicate with the remote server, wherein the secure element memory isseparate from a mobile device memory included in the mobile device;means for executing the application included in the secure elementmemory in response to an NFC trigger by the POS or POE terminal.
 20. Thesystem of claim 19, wherein the NFC trigger is induction based.